--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Thanks for the expaination.  That makes perfect sense.  You are reading a hardware MPG counter in the Macro Pump rather than the AB Quadrature inputs.
>  
> A number of Users have commented on how much more responsive the MPG is under KFLOP control rather than in their previous controller.  This is because it is all performed within KFLOP with sub millisecond response.  The PC application running at 10Hz (occasionally worse) plus USB delays are not in the loop.  I'm surprised your experience is different.  Maybe it is because your MPG has lower resolution?
>  
> Regarding the chan[0].Dest : it will tell you where the axis is on an instantaneous basis which is exactly what you need.  On the KMotion Axis Screen the "Dest" column is exactly this variable displayed.  I don't know how to explain it any clearer than I did in my last email.  Please try using it to convince yourself.
>  
> And share your MPG code with this new feature after it is working :}
>  
> Regards
> TK
>  
>  
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, December 4, 2011 1:15 PM
> Subject: [DynoMotion] Re: Pendant Questions.....
>
>
>  
> Tom,
>
> I'm not sure I can agree with that.... If I home the machine, then do a MoveExp(0, 1000000000) then chan[0].Dest is NOT going to show me where the machine IS, but where it WILL be at some (unknown to me) time in the future. The whole problem I'm having with the smooth MPG is that if I turn the MPG quickly, while a large Factor is in effect, I can command a very large move, which will only complete many seconds AFTER I've stopped moving the MPG. This will likely result in the machine running into its limits. It's impossible for me to know how far it WILL move until it's done, since there is no feedback to the user. Your suggestion, as I understood it, was to limit how far ahead I command moves(i.e. - clamp the delta between where the machine IS, and where the MPG code is telling it to go, to something like an inch or two), but I can't do that without knowing where the machine IS NOW, rather than where it WILL BE when it stops moving. Am I missing
> something here? It seems to me the smooth MPG mode is really only suitable for relatively small/slow moves, where Factor is kept to a low value, no? I think what I'm looking for is a hybrid jog, where it uses MoveExp for small values of Factor, and Jog for larger ones, so the jog speed transitions from a small increment step jog at very low MPG rotation rates, to a high-speed continuous Jog, ideally at rapid speed, at high MPG rotation rates.
>
> The other controllers I've worked with all keep an internal counter, be it hardware (SmoothStepper) or software (Mach3), that tracks the current commanded position, which will differ from the physical machine position only by any physical and servo lag. So, for all practical purposes, I can KNOW, to within a fairly small error, where the machine actually SHOULD be at any time.
>
> I suspected your MPG code was doing something predictive like that, but couldn't follow the logic. I've been unable to spin my MPG fast enough to come close to losing steps with the simple logic - Spinning as fast as I can, I average 20 passes, or about 4 mSec, between input changes, so I never see a count change of other than +/-1 or 0. I can see how this would be different with a higher resolution encoder - I think mine is about 50 counts/rev.
>
> In Mach3, Mach3 itself monitors the MPG inputs, and maintains a position DRO, and my macropump simply looks at the DRO. Mach3 also handles all the high-rate jogging control, I simply have to tell it when to enable jogging, on what axis, at what speed, and in what mode, and it does the rest. As I said, my pendant is connected through a serial Modbus controller, and it works perfectly like this. It works identically when connected to SmoothStepper inputs, whether the SS I/F is USB or Ethernet. So, the 10Hz macropump rate is more than adequate for controlling jogging in the way I need to. The only place where the 10Hz update rate affects me at all is in handling double-clicks on the pendant button. Due to the 10Hz macropump rate, the user can pretty easily double click too quickly for it to be captured properly.
>
> I believe (but I'm not sure) the SmoothStepper likely implements the MPG counter in hardware in the FPGA, and simply refreshes the Mach3 MPG counter at its normal update rate of 50Hz. It's entirely possible the ModIO does the same thing. But, the point is, that's all transparent to the user, who simply has to properly configure the MPGA/B inputs to the correct "pins", and the rest is handled in the plug-ins and device firmware, so it all looks exactly like an MPG connected to a parallel port to the user.
>
> I believe the Mach3 interface used for jogging is essentially what you have in the Jog() function - Mach3 tells the device to "move this axis at this speed, in this direction", and then comes back later and tells it when it's time to stop. There is also a "failsafe", at least in the SS code, that will stop a jog if it fails to receive a periodic update from Mach3, to prevent runaways.
>
> If you wanted to make life MUCH easier for Mach3 users, it seems to me there's no reason essentially the same functionality could not be implemented in the KFlop plug-in. I'd be willing to bet you could also implement a set of canned DSP code for Mach3 users that would support at least 99% of the most-used Mach3 functionality with no programming required on the users part, beyond perhaps axis configuration init, and a few other minor things in the plug-in configuration. Virtually all other needed information should be available through the plug-in from the standard Mach3 configuration dialogs. This is basically how the SS works, and makes the change from parallel port to SS incredibly painless - it took me mere minutes the first time I did it.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Again it seems we have a terminology/communication issue.  Obviously without encoder feedback connected to KFLOP it is impossible for KFLOP to truely know the current machine position.  However it does know the current position it commanded the servos.  If nothing catastrophic happened the Commanded Destination and the Actual Position should match except a small servo following error.  So for the purposes of limiting jog motion we can use chan[x].Dest to know where we are.  In fact for purposes of limiting the trajectory rate that might even be more logical.
>
> >  
> > The MPG Code you have looks great (although a subtract with sign extend might be slightly faster than the table lookup approach).
>
> >  
> > The original code did more than simple quadrature counting.  Your code is limited to counting at 5.555KHz because every quadrature transition must be observed by the algorithm and the code only runs 5,555 times per second (one time slice every 180us).  I've tested the other algorithm at over 100KHz by feeding the same encoder signals into both a hardware encoder input and the software routine and the counts match perfectly.  The technique allows more than just one encoder count per sample.  It keeps track of the last two deltas and uses that to predict the next.  So for example at 100KHz the last two deltas might have been 19 and 20 counts.  So it assumes the next delta should be close to 19.5 counts.  As long as the real change is within +/- 1 count of the prediction it works.  It works well because a change in speed of 5% in a small fraction of a millisecond would correspond to ramp up to full speed in several
> milliseconds which for most
> > systems is far beyond possibility.  However the big disadvantage of the algorithm is that it gets confused with any noise inputs.  The prediction stuff can be eliminated most simply by substituting zero for the last two deltas so then it just picks the delta closest to zero or -1, 0 , +1  counts.  Change:
> >  
> >   DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> >
> > to
> >  
> >   DiffX2 = 2*(Pos-PosNoWrap);
> >
> >  
> > BTW how you were able to monitor an MPG under a Mach3 Macro pump running at ~ 10Hz is totally beyond me.
> >  
> > Regards
> > TK
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, December 4, 2011 10:32 AM
> > Subject: [DynoMotion] Re: Pendant Questions.....
> >
> >
> >  
> > Tom,
> >
> > The point was you indicated that I DID know the current machine position, so I could limit the jog distance "look-ahead" to prevent over-run. But, it appears that without encoders connected to the KFlop, I do NOT know the *current* machine position while it is in motion, right? But how do YOU track position, if there is no current position variable?
> >
> > I seem to have the MPG all working nicely now. I'd like to think I simplified the code a bit. I couldn't make sense of the MPG wrap-around logic you had, so I just put in my own very simple (if, perhaps, a bit brute force) code, which seems to work perfectly:
> >
> > int MPGPos, LastMPGPos, MPGChange;
> > char QuadTbl[16] =
> > {
> > // Gives delta from last MPG pos
> > // Rows are by last MPG Pos
> > // Columns are by current MPG Pos
> > 0, 1, 0, -1, // LastPos = 0
> > -1, 0, 1, 0, // LastPos = 1
> > 0, -1, 0, 1, // LastPos = 2
> > 1, 0, -1, 0 // LastPos = 3
> > };
> >
> > LastMPGPos = MPGPos;
> > // Gives 0,1,2,3 or 3,2,1,0 sequence
> > MPGPos = (MPGBitB << 1) | (MPGBitB ^ MPGBitA);
> > // Accounts for wrap-around
> > MPGChange = QuadTbl[(LastMPGPos << 2) + MPGPos];
> >
> > Am I missing something your code does that this doesn't?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > Well for your purposes you would probably want to use the Commanded Dest anyways.  So I don't get your point.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, December 3, 2011 8:16 PM
> > > Subject: [DynoMotion] Re: Pendant Questions.....
> > >
> > >
> > >  
> > > Tom,
> > >
> > > The "only valid with a feedback device" - is the killer. I'm using Geckos, so the encoders are not connected to the KFlop.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > > ÃÆ'‚ 
> > > > You know both.ÃÆ'‚  The terminology is probably confusing.ÃÆ'‚  It is more geared toward servos. Where the "Destination" is where the servo is trying to beÃÆ'‚ - which may or may not be a moving target depeding on if a trajectory is in progress.ÃÆ'‚ 
> > > > ÃÆ'‚ 
> > > > So the variables are:
> > > > ÃÆ'‚ 
> > > > PositionÃÆ'‚ = where youÃÆ'‚ really are right now (only valid with a feedback device)
> > > > ÃÆ'‚ 
> > > > Dest = where you are supposed to be right now
> > > > ÃÆ'‚ LastMotionDest = Final dest of the last motion command
> > > > ÃÆ'‚ LastMotionType = Type of last Trajectory commandedLAST_MOTION_JOG 0 // type of last independent motion was a jogÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MOVE 1 // type of last independent motion was a moveÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MULTI 2 // type of last independent motion was a multi axis move (G0 type)ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_EXP 3 // type of last independent motion was an exponential
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #define
> > > > ÃÆ'‚ 
> > > > These are all declared and commented in KMotionDef.h.
> > > > ÃÆ'‚ 
> > > > Regards
> > > > TK
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Saturday, December 3, 2011 3:07 PM
> > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > >
> > > >
> > > > ÃÆ'‚ 
> > > > Tom,
> > > >
> > > > You indicated earlier that I DO know where the axis is, but now you seem to be saying I don't, that I just know where it's going. Do I know what its current position is or not. If so, then how??
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > chan[n].Dest would be the current commanded destination (you don't have position feedback).
> > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > Sounds like you have a bug and are corrupting something.ÃÆ'Æ'‚ÃÆ'‚  If you send me your code I can look it over.
> > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > Regards
> > > > > TK
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Saturday, December 3, 2011 11:14 AM
> > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > >
> > > > >
> > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > Tom,
> > > > >
> > > > > Smoothing is set to the default value. Funny thing is, I can also get it to move well above the max speed (200 IPM) - I can sometimes make it move 50" in about 5 seconds!
> > > > >
> > > > > "But also btw you do know where you are at all times." - How? I've tried using chan[n].Position, but I seem to get erratic results.
> > > > >
> > > > > I'm getting something else rather baffling as well. I can get it to a state where one or more of the DROs gets clobbered - just changes instantly to some really huge number, that fills the DRO with digits, even over-writing the axis legend. This seems to happen at least sometimes when I do a Jog(n, 0.0) to stop motion.
> > > > >
> > > > > And, I often find when I modify the code, and do an Init in KMCNC, the board goes out to lunch, and needs to be power-cycled to get it back. Downloading the same code after power-cycling always works fine. Shouldn't the download be more bullet-proof than that?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > I think what is happening is that if you move the position faster than the max velocity then the MoveExp limits to the max velocity and the position falls behind and the position catches up after you slow down or stop.
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Another possibility is that you have the smoothing set so high that it lags behind by a huge amount.
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > An exponential move takes forever to get to a final position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  It just keeps converging closer and closer as time passes.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So after some specified time of no encoder motion it just does a linear move of the last tiny bit so the move completes.
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > I guess by "User Stopped" you mean less than a certain movement (1 count) over a certain period of time?ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  There really is no such thing as exactly "Stopped".ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But if you decide based on someÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ criteria that you wish to suddenly stopÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ you can issue a Jog(0,0); to stop without needing to know where you are.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But also btw you do know where you are at all times.
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > A better solution might be to put a limit on the target position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  The way an exponential move works is that as the target position moves around more or less randomly at the whim of the Operator the exponential move will always be trying to move toward the target at a speed that is proportional to how far the target is away.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So by putting a clamp on the target position to within some tolerance of the current position (maybe 1 inch) then if the Operator suddenly flicks the position 10 inches away 9 inches of the change will be ignored.
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Regards
> > > > > > TK
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Saturday, December 3, 2011 8:28 AM
> > > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > > >
> > > > > >
> > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Tom,
> > > > > >
> > > > > > I'm confused about some of the "smooth" jogging logic. The move is programmed using MoveExp, but then there's the other "if" clause to "finalize" the move (when the axis changes, or when no MPG change occurs for one second), which programs a Move() to the same target position as the previous MoveExp(). Why is this necessary?
> > > > > >
> > > > > > I'm also finding that at times, if Factor is set to some higher value (like 20.0) that the axis will sometimes continue moving for several seconds, and a pretty good distance, AFTER I stop turning the MPG. I would very much prefer movement stop ASAP after I stop turning the MPG, but can't figure out how to do that, since I don't know where the axis is.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I think we discussed this before when you had the Mach3 arrow key runaway.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  ButÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ the standard software MPG method hasÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ a technique to handle very high speed encoders however it gets confused if your wiring has noise.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  To defeat the speed
> enhancement change:ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > to
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap);
> > > > > > >
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > We also discussed using the MPGSmooth.c technique instead.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > We can probably add a mechanism to let KFLOP know that GCode is running by setting a virtual bit for example if you find that important.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Regards
> > > > > > > TK
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > Sent: Friday, December 2, 2011 12:04 PM
> > > > > > > Subject: [DynoMotion] Pendant Questions.....
> > > > > > >
> > > > > > >
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I'm finally starting to bring up my pendant, and (surprise!) have run into at least one oddity, and some things I don't know how to implement.
> > > > > > >
> > > > > > > First, the MPG. I'm using the MPG code from Init3AnalogPlusMPG.c. It *sorta* works, but strangely. When I turn the MPG slowly, it seems to work OK. But, once I turn it beyond a relatively slow speed, the axis being jogged takes off at a pretty good clip, and just runs, literally, forever.
> > > > > > >
> > > > > > > Next, I've got a bunch of "button" functions, some of which are trivial (Execute, Halt, spindle/coolant on/off), but others less so, and I wonder if they even CAN be implemented under KMotionCNC. With Mach3, my pendant is ordinarily operated by a macropump driver, so it's easy to keep Mach3 and the hardware in-sync, and the pendant driver knows the state of Mach3. This allows me to make the button functions "state-aware". For example, a single button will do a CycleStart if no G-code program is currently running, or a Stop, if a G-code program is currently running. I have another button that serves the dual functions of FeedHold/Rewind. With KMotionCNC, it appears to me not practical to duplicate this, since the DSP has no clue whether a program is running or not. Is that correct?
> > > > > > >
> > > > > > > Also, in Mach3, both G00 and manual toolchanges are terminated by pressing CycleStart, but it appears to me that in KMotionCNC, a G00 is terminated by hitting "Execute", but a manual toolchange, which pops up a dialog, can only be exited by hitting Enter, or clicking with the mouse. Is there a way around this, to make them both accept the same button-triggered action?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> OK, I'll try using Dest. I thought you had indicated previously that it did not give instantaneous position. Now it makes a lot more sense.
>
> I can see where a high-resolution MPG might get sluggish over USB, but aren't they typically pretty low-resolution, like 50-100 counts/rev? I've only ever used a couple.... Clearly having it run entirely on the KFlop has advantages, but I'm just suggesting for ease of setup, supporting the "Mach3 way" in the plug-in would make life a LOT simpler for non-programmer Mach3 users (and most people who mess with these machines are NOT programmers - Most of them struggle with even very simple VB macros!) I would think it could significantly expand your potential market, and reduce hand-holding.
>
> Heck, I've spent several days of my spare time over the last few weeks getting to the point where I have enough functionality to finally be able to consider switching out my SS for the KFLop. That's compared to, quite literally, only about 10-15 minutes to get my SmoothStepper up and running the first time with ALL the same functionality (actually a bit more...). VERY few of the CNC guys I know would've ever been able to make it to this point.
>
> I plan to hook the KFlop up to the machine tomorrow, so we'll see how badly I've screwed things up. :-)
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Thanks for the expaination.  That makes perfect sense.  You are reading a hardware MPG counter in the Macro Pump rather than the AB Quadrature inputs.
> >  
> > A number of Users have commented on how much more responsive the MPG is under KFLOP control rather than in their previous controller.  This is because it is all performed within KFLOP with sub millisecond response.  The PC application running at 10Hz (occasionally worse) plus USB delays are not in the loop.  I'm surprised your experience is different.  Maybe it is because your MPG has lower resolution?
> >  
> > Regarding the chan[0].Dest : it will tell you where the axis is on an instantaneous basis which is exactly what you need.  On the KMotion Axis Screen the "Dest" column is exactly this variable displayed.  I don't know how to explain it any clearer than I did in my last email.  Please try using it to convince yourself.
> >  
> > And share your MPG code with this new feature after it is working :}
> >  
> > Regards
> > TK
> >  
> >  
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, December 4, 2011 1:15 PM
> > Subject: [DynoMotion] Re: Pendant Questions.....
> >
> >
> >  
> > Tom,
> >
> > I'm not sure I can agree with that.... If I home the machine, then do a MoveExp(0, 1000000000) then chan[0].Dest is NOT going to show me where the machine IS, but where it WILL be at some (unknown to me) time in the future. The whole problem I'm having with the smooth MPG is that if I turn the MPG quickly, while a large Factor is in effect, I can command a very large move, which will only complete many seconds AFTER I've stopped moving the MPG. This will likely result in the machine running into its limits. It's impossible for me to know how far it WILL move until it's done, since there is no feedback to the user. Your suggestion, as I understood it, was to limit how far ahead I command moves(i.e. - clamp the delta between where the machine IS, and where the MPG code is telling it to go, to something like an inch or two), but I can't do that without knowing where the machine IS NOW, rather than where it WILL BE when it stops moving. Am I missing
> > something here? It seems to me the smooth MPG mode is really only suitable for relatively small/slow moves, where Factor is kept to a low value, no? I think what I'm looking for is a hybrid jog, where it uses MoveExp for small values of Factor, and Jog for larger ones, so the jog speed transitions from a small increment step jog at very low MPG rotation rates, to a high-speed continuous Jog, ideally at rapid speed, at high MPG rotation rates.
> >
> > The other controllers I've worked with all keep an internal counter, be it hardware (SmoothStepper) or software (Mach3), that tracks the current commanded position, which will differ from the physical machine position only by any physical and servo lag. So, for all practical purposes, I can KNOW, to within a fairly small error, where the machine actually SHOULD be at any time.
> >
> > I suspected your MPG code was doing something predictive like that, but couldn't follow the logic. I've been unable to spin my MPG fast enough to come close to losing steps with the simple logic - Spinning as fast as I can, I average 20 passes, or about 4 mSec, between input changes, so I never see a count change of other than +/-1 or 0. I can see how this would be different with a higher resolution encoder - I think mine is about 50 counts/rev.
> >
> > In Mach3, Mach3 itself monitors the MPG inputs, and maintains a position DRO, and my macropump simply looks at the DRO. Mach3 also handles all the high-rate jogging control, I simply have to tell it when to enable jogging, on what axis, at what speed, and in what mode, and it does the rest. As I said, my pendant is connected through a serial Modbus controller, and it works perfectly like this. It works identically when connected to SmoothStepper inputs, whether the SS I/F is USB or Ethernet. So, the 10Hz macropump rate is more than adequate for controlling jogging in the way I need to. The only place where the 10Hz update rate affects me at all is in handling double-clicks on the pendant button. Due to the 10Hz macropump rate, the user can pretty easily double click too quickly for it to be captured properly.
> >
> > I believe (but I'm not sure) the SmoothStepper likely implements the MPG counter in hardware in the FPGA, and simply refreshes the Mach3 MPG counter at its normal update rate of 50Hz. It's entirely possible the ModIO does the same thing. But, the point is, that's all transparent to the user, who simply has to properly configure the MPGA/B inputs to the correct "pins", and the rest is handled in the plug-ins and device firmware, so it all looks exactly like an MPG connected to a parallel port to the user.
> >
> > I believe the Mach3 interface used for jogging is essentially what you have in the Jog() function - Mach3 tells the device to "move this axis at this speed, in this direction", and then comes back later and tells it when it's time to stop. There is also a "failsafe", at least in the SS code, that will stop a jog if it fails to receive a periodic update from Mach3, to prevent runaways.
> >
> > If you wanted to make life MUCH easier for Mach3 users, it seems to me there's no reason essentially the same functionality could not be implemented in the KFlop plug-in. I'd be willing to bet you could also implement a set of canned DSP code for Mach3 users that would support at least 99% of the most-used Mach3 functionality with no programming required on the users part, beyond perhaps axis configuration init, and a few other minor things in the plug-in configuration. Virtually all other needed information should be available through the plug-in from the standard Mach3 configuration dialogs. This is basically how the SS works, and makes the change from parallel port to SS incredibly painless - it took me mere minutes the first time I did it.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > Again it seems we have a terminology/communication issue.  Obviously without encoder feedback connected to KFLOP it is impossible for KFLOP to truely know the current machine position.  However it does know the current position it commanded the servos.  If nothing catastrophic happened the Commanded Destination and the Actual Position should match except a small servo following error.  So for the purposes of limiting jog motion we can use chan[x].Dest to know where we are.  In fact for purposes of limiting the trajectory rate that might even be more logical.
> >
> > >  
> > > The MPG Code you have looks great (although a subtract with sign extend might be slightly faster than the table lookup approach).
> >
> > >  
> > > The original code did more than simple quadrature counting.  Your code is limited to counting at 5.555KHz because every quadrature transition must be observed by the algorithm and the code only runs 5,555 times per second (one time slice every 180us).  I've tested the other algorithm at over 100KHz by feeding the same encoder signals into both a hardware encoder input and the software routine and the counts match perfectly.  The technique allows more than just one encoder count per sample.  It keeps track of the last two deltas and uses that to predict the next.  So for example at 100KHz the last two deltas might have been 19 and 20 counts.  So it assumes the next delta should be close to 19.5 counts.  As long as the real change is within +/- 1 count of the prediction it works.  It works well because a change in speed of 5% in a small fraction of a millisecond would correspond to ramp up to full speed in several
> > milliseconds which for most
> > > systems is far beyond possibility.  However the big disadvantage of the algorithm is that it gets confused with any noise inputs.  The prediction stuff can be eliminated most simply by substituting zero for the last two deltas so then it just picks the delta closest to zero or -1, 0 , +1  counts.  Change:
> > >  
> > >   DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> > >
> > > to
> > >  
> > >   DiffX2 = 2*(Pos-PosNoWrap);
> > >
> > >  
> > > BTW how you were able to monitor an MPG under a Mach3 Macro pump running at ~ 10Hz is totally beyond me.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, December 4, 2011 10:32 AM
> > > Subject: [DynoMotion] Re: Pendant Questions.....
> > >
> > >
> > >  
> > > Tom,
> > >
> > > The point was you indicated that I DID know the current machine position, so I could limit the jog distance "look-ahead" to prevent over-run. But, it appears that without encoders connected to the KFlop, I do NOT know the *current* machine position while it is in motion, right? But how do YOU track position, if there is no current position variable?
> > >
> > > I seem to have the MPG all working nicely now. I'd like to think I simplified the code a bit. I couldn't make sense of the MPG wrap-around logic you had, so I just put in my own very simple (if, perhaps, a bit brute force) code, which seems to work perfectly:
> > >
> > > int MPGPos, LastMPGPos, MPGChange;
> > > char QuadTbl[16] =
> > > {
> > > // Gives delta from last MPG pos
> > > // Rows are by last MPG Pos
> > > // Columns are by current MPG Pos
> > > 0, 1, 0, -1, // LastPos = 0
> > > -1, 0, 1, 0, // LastPos = 1
> > > 0, -1, 0, 1, // LastPos = 2
> > > 1, 0, -1, 0 // LastPos = 3
> > > };
> > >
> > > LastMPGPos = MPGPos;
> > > // Gives 0,1,2,3 or 3,2,1,0 sequence
> > > MPGPos = (MPGBitB << 1) | (MPGBitB ^ MPGBitA);
> > > // Accounts for wrap-around
> > > MPGChange = QuadTbl[(LastMPGPos << 2) + MPGPos];
> > >
> > > Am I missing something your code does that this doesn't?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > Well for your purposes you would probably want to use the Commanded Dest anyways.  So I don't get your point.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Saturday, December 3, 2011 8:16 PM
> > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > The "only valid with a feedback device" - is the killer. I'm using Geckos, so the encoders are not connected to the KFlop.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > > ÃÆ'‚ 
> > > > > You know both.ÃÆ'‚  The terminology is probably confusing.ÃÆ'‚  It is more geared toward servos. Where the "Destination" is where the servo is trying to beÃÆ'‚ - which may or may not be a moving target depeding on if a trajectory is in progress.ÃÆ'‚ 
> > > > > ÃÆ'‚ 
> > > > > So the variables are:
> > > > > ÃÆ'‚ 
> > > > > PositionÃÆ'‚ = where youÃÆ'‚ really are right now (only valid with a feedback device)
> > > > > ÃÆ'‚ 
> > > > > Dest = where you are supposed to be right now
> > > > > ÃÆ'‚ LastMotionDest = Final dest of the last motion command
> > > > > ÃÆ'‚ LastMotionType = Type of last Trajectory commandedLAST_MOTION_JOG 0 // type of last independent motion was a jogÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MOVE 1 // type of last independent motion was a moveÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MULTI 2 // type of last independent motion was a multi axis move (G0 type)ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_EXP 3 // type of last independent motion was an exponential
> > > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #define
> > > > > ÃÆ'‚ 
> > > > > These are all declared and commented in KMotionDef.h.
> > > > > ÃÆ'‚ 
> > > > > Regards
> > > > > TK
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Saturday, December 3, 2011 3:07 PM
> > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > >
> > > > >
> > > > > ÃÆ'‚ 
> > > > > Tom,
> > > > >
> > > > > You indicated earlier that I DO know where the axis is, but now you seem to be saying I don't, that I just know where it's going. Do I know what its current position is or not. If so, then how??
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > chan[n].Dest would be the current commanded destination (you don't have position feedback).
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Sounds like you have a bug and are corrupting something.ÃÆ'Æ'‚ÃÆ'‚  If you send me your code I can look it over.
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Saturday, December 3, 2011 11:14 AM
> > > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > > >
> > > > > >
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Tom,
> > > > > >
> > > > > > Smoothing is set to the default value. Funny thing is, I can also get it to move well above the max speed (200 IPM) - I can sometimes make it move 50" in about 5 seconds!
> > > > > >
> > > > > > "But also btw you do know where you are at all times." - How? I've tried using chan[n].Position, but I seem to get erratic results.
> > > > > >
> > > > > > I'm getting something else rather baffling as well. I can get it to a state where one or more of the DROs gets clobbered - just changes instantly to some really huge number, that fills the DRO with digits, even over-writing the axis legend. This seems to happen at least sometimes when I do a Jog(n, 0.0) to stop motion.
> > > > > >
> > > > > > And, I often find when I modify the code, and do an Init in KMCNC, the board goes out to lunch, and needs to be power-cycled to get it back. Downloading the same code after power-cycling always works fine. Shouldn't the download be more bullet-proof than that?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I think what is happening is that if you move the position faster than the max velocity then the MoveExp limits to the max velocity and the position falls behind and the position catches up after you slow down or stop.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Another possibility is that you have the smoothing set so high that it lags behind by a huge amount.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > An exponential move takes forever to get to a final position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  It just keeps converging closer and closer as time passes.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So after some specified time of no encoder motion it just does a linear move of the last tiny bit so the move completes.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I guess by "User Stopped" you mean less than a certain movement (1 count) over a certain period of time?ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  There really is no such thing as exactly "Stopped".ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But if you decide based on someÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ criteria that you wish to suddenly stopÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ you can issue a Jog(0,0); to stop without needing to know where you are.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But also btw you do know where you are at all times.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > A better solution might be to put a limit on the target position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  The way an exponential move works is that as the target position moves around more or less randomly at the whim of the Operator the exponential move will always be trying to move toward the target at a speed that is proportional to how far the target is away.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So by putting a clamp on the target position to within some tolerance of the current position (maybe 1 inch) then if the Operator suddenly flicks the position 10 inches away 9 inches of the change will be ignored.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Regards
> > > > > > > TK
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > Sent: Saturday, December 3, 2011 8:28 AM
> > > > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > > > >
> > > > > > >
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Tom,
> > > > > > >
> > > > > > > I'm confused about some of the "smooth" jogging logic. The move is programmed using MoveExp, but then there's the other "if" clause to "finalize" the move (when the axis changes, or when no MPG change occurs for one second), which programs a Move() to the same target position as the previous MoveExp(). Why is this necessary?
> > > > > > >
> > > > > > > I'm also finding that at times, if Factor is set to some higher value (like 20.0) that the axis will sometimes continue moving for several seconds, and a pretty good distance, AFTER I stop turning the MPG. I would very much prefer movement stop ASAP after I stop turning the MPG, but can't figure out how to do that, since I don't know where the axis is.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > I think we discussed this before when you had the Mach3 arrow key runaway.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  ButÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ the standard software MPG method hasÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ a technique to handle very high speed encoders however it gets confused if your wiring has noise.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  To defeat the speed
> > enhancement change:ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > to
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap);
> > > > > > > >
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > We also discussed using the MPGSmooth.c technique instead.
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > We can probably add a mechanism to let KFLOP know that GCode is running by setting a virtual bit for example if you find that important.
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > > Sent: Friday, December 2, 2011 12:04 PM
> > > > > > > > Subject: [DynoMotion] Pendant Questions.....
> > > > > > > >
> > > > > > > >
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > I'm finally starting to bring up my pendant, and (surprise!) have run into at least one oddity, and some things I don't know how to implement.
> > > > > > > >
> > > > > > > > First, the MPG. I'm using the MPG code from Init3AnalogPlusMPG.c. It *sorta* works, but strangely. When I turn the MPG slowly, it seems to work OK. But, once I turn it beyond a relatively slow speed, the axis being jogged takes off at a pretty good clip, and just runs, literally, forever.
> > > > > > > >
> > > > > > > > Next, I've got a bunch of "button" functions, some of which are trivial (Execute, Halt, spindle/coolant on/off), but others less so, and I wonder if they even CAN be implemented under KMotionCNC. With Mach3, my pendant is ordinarily operated by a macropump driver, so it's easy to keep Mach3 and the hardware in-sync, and the pendant driver knows the state of Mach3. This allows me to make the button functions "state-aware". For example, a single button will do a CycleStart if no G-code program is currently running, or a Stop, if a G-code program is currently running. I have another button that serves the dual functions of FeedHold/Rewind. With KMotionCNC, it appears to me not practical to duplicate this, since the DSP has no clue whether a program is running or not. Is that correct?
> > > > > > > >
> > > > > > > > Also, in Mach3, both G00 and manual toolchanges are terminated by pressing CycleStart, but it appears to me that in KMotionCNC, a G00 is terminated by hitting "Execute", but a manual toolchange, which pops up a dialog, can only be exited by hitting Enter, or clicking with the mouse. Is there a way around this, to make them both accept the same button-triggered action?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

 

Tom,

Limiting the distance I command ahead of current position appears to work very nicely. I clamp MPGTarget to no more than 1" from the current Dest. It appears I can get up to full rapid speed, and when I stop the MPG, the machine stops within about an inch - quite acceptable. This, of course, is in simulation. If it works as well on the actual machine tomorrow I'll be in business.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> OK, I'll try using Dest. I thought you had indicated previously that it did not give instantaneous position. Now it makes a lot more sense.
>
> I can see where a high-resolution MPG might get sluggish over USB, but aren't they typically pretty low-resolution, like 50-100 counts/rev? I've only ever used a couple.... Clearly having it run entirely on the KFlop has advantages, but I'm just suggesting for ease of setup, supporting the "Mach3 way" in the plug-in would make life a LOT simpler for non-programmer Mach3 users (and most people who mess with these machines are NOT programmers - Most of them struggle with even very simple VB macros!) I would think it could significantly expand your potential market, and reduce hand-holding.
>
> Heck, I've spent several days of my spare time over the last few weeks getting to the point where I have enough functionality to finally be able to consider switching out my SS for the KFLop. That's compared to, quite literally, only about 10-15 minutes to get my SmoothStepper up and running the first time with ALL the same functionality (actually a bit more...). VERY few of the CNC guys I know would've ever been able to make it to this point.
>
> I plan to hook the KFlop up to the machine tomorrow, so we'll see how badly I've screwed things up. :-)
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Thanks for the expaination.  That makes perfect sense.  You are reading a hardware MPG counter in the Macro Pump rather than the AB Quadrature inputs.
> >  
> > A number of Users have commented on how much more responsive the MPG is under KFLOP control rather than in their previous controller.  This is because it is all performed within KFLOP with sub millisecond response.  The PC application running at 10Hz (occasionally worse) plus USB delays are not in the loop.  I'm surprised your experience is different.  Maybe it is because your MPG has lower resolution?
> >  
> > Regarding the chan[0].Dest : it will tell you where the axis is on an instantaneous basis which is exactly what you need.  On the KMotion Axis Screen the "Dest" column is exactly this variable displayed.  I don't know how to explain it any clearer than I did in my last email.  Please try using it to convince yourself.
> >  
> > And share your MPG code with this new feature after it is working :}
> >  
> > Regards
> > TK
> >  
> >  
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, December 4, 2011 1:15 PM
> > Subject: [DynoMotion] Re: Pendant Questions.....
> >
> >
> >  
> > Tom,
> >
> > I'm not sure I can agree with that.... If I home the machine, then do a MoveExp(0, 1000000000) then chan[0].Dest is NOT going to show me where the machine IS, but where it WILL be at some (unknown to me) time in the future. The whole problem I'm having with the smooth MPG is that if I turn the MPG quickly, while a large Factor is in effect, I can command a very large move, which will only complete many seconds AFTER I've stopped moving the MPG. This will likely result in the machine running into its limits. It's impossible for me to know how far it WILL move until it's done, since there is no feedback to the user. Your suggestion, as I understood it, was to limit how far ahead I command moves(i.e. - clamp the delta between where the machine IS, and where the MPG code is telling it to go, to something like an inch or two), but I can't do that without knowing where the machine IS NOW, rather than where it WILL BE when it stops moving. Am I missing
> > something here? It seems to me the smooth MPG mode is really only suitable for relatively small/slow moves, where Factor is kept to a low value, no? I think what I'm looking for is a hybrid jog, where it uses MoveExp for small values of Factor, and Jog for larger ones, so the jog speed transitions from a small increment step jog at very low MPG rotation rates, to a high-speed continuous Jog, ideally at rapid speed, at high MPG rotation rates.
> >
> > The other controllers I've worked with all keep an internal counter, be it hardware (SmoothStepper) or software (Mach3), that tracks the current commanded position, which will differ from the physical machine position only by any physical and servo lag. So, for all practical purposes, I can KNOW, to within a fairly small error, where the machine actually SHOULD be at any time.
> >
> > I suspected your MPG code was doing something predictive like that, but couldn't follow the logic. I've been unable to spin my MPG fast enough to come close to losing steps with the simple logic - Spinning as fast as I can, I average 20 passes, or about 4 mSec, between input changes, so I never see a count change of other than +/-1 or 0. I can see how this would be different with a higher resolution encoder - I think mine is about 50 counts/rev.
> >
> > In Mach3, Mach3 itself monitors the MPG inputs, and maintains a position DRO, and my macropump simply looks at the DRO. Mach3 also handles all the high-rate jogging control, I simply have to tell it when to enable jogging, on what axis, at what speed, and in what mode, and it does the rest. As I said, my pendant is connected through a serial Modbus controller, and it works perfectly like this. It works identically when connected to SmoothStepper inputs, whether the SS I/F is USB or Ethernet. So, the 10Hz macropump rate is more than adequate for controlling jogging in the way I need to. The only place where the 10Hz update rate affects me at all is in handling double-clicks on the pendant button. Due to the 10Hz macropump rate, the user can pretty easily double click too quickly for it to be captured properly.
> >
> > I believe (but I'm not sure) the SmoothStepper likely implements the MPG counter in hardware in the FPGA, and simply refreshes the Mach3 MPG counter at its normal update rate of 50Hz. It's entirely possible the ModIO does the same thing. But, the point is, that's all transparent to the user, who simply has to properly configure the MPGA/B inputs to the correct "pins", and the rest is handled in the plug-ins and device firmware, so it all looks exactly like an MPG connected to a parallel port to the user.
> >
> > I believe the Mach3 interface used for jogging is essentially what you have in the Jog() function - Mach3 tells the device to "move this axis at this speed, in this direction", and then comes back later and tells it when it's time to stop. There is also a "failsafe", at least in the SS code, that will stop a jog if it fails to receive a periodic update from Mach3, to prevent runaways.
> >
> > If you wanted to make life MUCH easier for Mach3 users, it seems to me there's no reason essentially the same functionality could not be implemented in the KFlop plug-in. I'd be willing to bet you could also implement a set of canned DSP code for Mach3 users that would support at least 99% of the most-used Mach3 functionality with no programming required on the users part, beyond perhaps axis configuration init, and a few other minor things in the plug-in configuration. Virtually all other needed information should be available through the plug-in from the standard Mach3 configuration dialogs. This is basically how the SS works, and makes the change from parallel port to SS incredibly painless - it took me mere minutes the first time I did it.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > Again it seems we have a terminology/communication issue.  Obviously without encoder feedback connected to KFLOP it is impossible for KFLOP to truely know the current machine position.  However it does know the current position it commanded the servos.  If nothing catastrophic happened the Commanded Destination and the Actual Position should match except a small servo following error.  So for the purposes of limiting jog motion we can use chan[x].Dest to know where we are.  In fact for purposes of limiting the trajectory rate that might even be more logical.
> >
> > >  
> > > The MPG Code you have looks great (although a subtract with sign extend might be slightly faster than the table lookup approach).
> >
> > >  
> > > The original code did more than simple quadrature counting.  Your code is limited to counting at 5.555KHz because every quadrature transition must be observed by the algorithm and the code only runs 5,555 times per second (one time slice every 180us).  I've tested the other algorithm at over 100KHz by feeding the same encoder signals into both a hardware encoder input and the software routine and the counts match perfectly.  The technique allows more than just one encoder count per sample.  It keeps track of the last two deltas and uses that to predict the next.  So for example at 100KHz the last two deltas might have been 19 and 20 counts.  So it assumes the next delta should be close to 19.5 counts.  As long as the real change is within +/- 1 count of the prediction it works.  It works well because a change in speed of 5% in a small fraction of a millisecond would correspond to ramp up to full speed in several
> > milliseconds which for most
> > > systems is far beyond possibility.  However the big disadvantage of the algorithm is that it gets confused with any noise inputs.  The prediction stuff can be eliminated most simply by substituting zero for the last two deltas so then it just picks the delta closest to zero or -1, 0 , +1  counts.  Change:
> > >  
> > >   DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> > >
> > > to
> > >  
> > >   DiffX2 = 2*(Pos-PosNoWrap);
> > >
> > >  
> > > BTW how you were able to monitor an MPG under a Mach3 Macro pump running at ~ 10Hz is totally beyond me.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, December 4, 2011 10:32 AM
> > > Subject: [DynoMotion] Re: Pendant Questions.....
> > >
> > >
> > >  
> > > Tom,
> > >
> > > The point was you indicated that I DID know the current machine position, so I could limit the jog distance "look-ahead" to prevent over-run. But, it appears that without encoders connected to the KFlop, I do NOT know the *current* machine position while it is in motion, right? But how do YOU track position, if there is no current position variable?
> > >
> > > I seem to have the MPG all working nicely now. I'd like to think I simplified the code a bit. I couldn't make sense of the MPG wrap-around logic you had, so I just put in my own very simple (if, perhaps, a bit brute force) code, which seems to work perfectly:
> > >
> > > int MPGPos, LastMPGPos, MPGChange;
> > > char QuadTbl[16] =
> > > {
> > > // Gives delta from last MPG pos
> > > // Rows are by last MPG Pos
> > > // Columns are by current MPG Pos
> > > 0, 1, 0, -1, // LastPos = 0
> > > -1, 0, 1, 0, // LastPos = 1
> > > 0, -1, 0, 1, // LastPos = 2
> > > 1, 0, -1, 0 // LastPos = 3
> > > };
> > >
> > > LastMPGPos = MPGPos;
> > > // Gives 0,1,2,3 or 3,2,1,0 sequence
> > > MPGPos = (MPGBitB << 1) | (MPGBitB ^ MPGBitA);
> > > // Accounts for wrap-around
> > > MPGChange = QuadTbl[(LastMPGPos << 2) + MPGPos];
> > >
> > > Am I missing something your code does that this doesn't?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > Well for your purposes you would probably want to use the Commanded Dest anyways.  So I don't get your point.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Saturday, December 3, 2011 8:16 PM
> > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > The "only valid with a feedback device" - is the killer. I'm using Geckos, so the encoders are not connected to the KFlop.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > > ÃÆ'‚ 
> > > > > You know both.ÃÆ'‚  The terminology is probably confusing.ÃÆ'‚  It is more geared toward servos. Where the "Destination" is where the servo is trying to beÃÆ'‚ - which may or may not be a moving target depeding on if a trajectory is in progress.ÃÆ'‚ 
> > > > > ÃÆ'‚ 
> > > > > So the variables are:
> > > > > ÃÆ'‚ 
> > > > > PositionÃÆ'‚ = where youÃÆ'‚ really are right now (only valid with a feedback device)
> > > > > ÃÆ'‚ 
> > > > > Dest = where you are supposed to be right now
> > > > > ÃÆ'‚ LastMotionDest = Final dest of the last motion command
> > > > > ÃÆ'‚ LastMotionType = Type of last Trajectory commandedLAST_MOTION_JOG 0 // type of last independent motion was a jogÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MOVE 1 // type of last independent motion was a moveÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_MULTI 2 // type of last independent motion was a multi axis move (G0 type)ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #defineLAST_MOTION_EXP 3 // type of last independent motion was an exponential
> > > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  #define
> > > > > ÃÆ'‚ 
> > > > > These are all declared and commented in KMotionDef.h.
> > > > > ÃÆ'‚ 
> > > > > Regards
> > > > > TK
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Saturday, December 3, 2011 3:07 PM
> > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > >
> > > > >
> > > > > ÃÆ'‚ 
> > > > > Tom,
> > > > >
> > > > > You indicated earlier that I DO know where the axis is, but now you seem to be saying I don't, that I just know where it's going. Do I know what its current position is or not. If so, then how??
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > chan[n].Dest would be the current commanded destination (you don't have position feedback).
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Sounds like you have a bug and are corrupting something.ÃÆ'Æ'‚ÃÆ'‚  If you send me your code I can look it over.
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Saturday, December 3, 2011 11:14 AM
> > > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > > >
> > > > > >
> > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > Tom,
> > > > > >
> > > > > > Smoothing is set to the default value. Funny thing is, I can also get it to move well above the max speed (200 IPM) - I can sometimes make it move 50" in about 5 seconds!
> > > > > >
> > > > > > "But also btw you do know where you are at all times." - How? I've tried using chan[n].Position, but I seem to get erratic results.
> > > > > >
> > > > > > I'm getting something else rather baffling as well. I can get it to a state where one or more of the DROs gets clobbered - just changes instantly to some really huge number, that fills the DRO with digits, even over-writing the axis legend. This seems to happen at least sometimes when I do a Jog(n, 0.0) to stop motion.
> > > > > >
> > > > > > And, I often find when I modify the code, and do an Init in KMCNC, the board goes out to lunch, and needs to be power-cycled to get it back. Downloading the same code after power-cycling always works fine. Shouldn't the download be more bullet-proof than that?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I think what is happening is that if you move the position faster than the max velocity then the MoveExp limits to the max velocity and the position falls behind and the position catches up after you slow down or stop.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Another possibility is that you have the smoothing set so high that it lags behind by a huge amount.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > An exponential move takes forever to get to a final position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  It just keeps converging closer and closer as time passes.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So after some specified time of no encoder motion it just does a linear move of the last tiny bit so the move completes.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > I guess by "User Stopped" you mean less than a certain movement (1 count) over a certain period of time?ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  There really is no such thing as exactly "Stopped".ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But if you decide based on someÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ criteria that you wish to suddenly stopÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ you can issue a Jog(0,0); to stop without needing to know where you are.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  But also btw you do know where you are at all times.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > A better solution might be to put a limit on the target position.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  The way an exponential move works is that as the target position moves around more or less randomly at the whim of the Operator the exponential move will always be trying to move toward the target at a speed that is proportional to how far the target is away.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  So by putting a clamp on the target position to within some tolerance of the current position (maybe 1 inch) then if the Operator suddenly flicks the position 10 inches away 9 inches of the change will be ignored.
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Regards
> > > > > > > TK
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > Sent: Saturday, December 3, 2011 8:28 AM
> > > > > > > Subject: [DynoMotion] Re: Pendant Questions.....
> > > > > > >
> > > > > > >
> > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > Tom,
> > > > > > >
> > > > > > > I'm confused about some of the "smooth" jogging logic. The move is programmed using MoveExp, but then there's the other "if" clause to "finalize" the move (when the axis changes, or when no MPG change occurs for one second), which programs a Move() to the same target position as the previous MoveExp(). Why is this necessary?
> > > > > > >
> > > > > > > I'm also finding that at times, if Factor is set to some higher value (like 20.0) that the axis will sometimes continue moving for several seconds, and a pretty good distance, AFTER I stop turning the MPG. I would very much prefer movement stop ASAP after I stop turning the MPG, but can't figure out how to do that, since I don't know where the axis is.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > I think we discussed this before when you had the Mach3 arrow key runaway.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  ButÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ the standard software MPG method hasÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ a technique to handle very high speed encoders however it gets confused if your wiring has noise.ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚  To defeat the speed
> > enhancement change:ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > to
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ DiffX2 = 2*(Pos-PosNoWrap);
> > > > > > > >
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > We also discussed using the MPGSmooth.c technique instead.
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > We can probably add a mechanism to let KFLOP know that GCode is running by setting a virtual bit for example if you find that important.
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > > Sent: Friday, December 2, 2011 12:04 PM
> > > > > > > > Subject: [DynoMotion] Pendant Questions.....
> > > > > > > >
> > > > > > > >
> > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'¢ÃÆ'¢â€šÂ¬ÃÆ'…¡ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > I'm finally starting to bring up my pendant, and (surprise!) have run into at least one oddity, and some things I don't know how to implement.
> > > > > > > >
> > > > > > > > First, the MPG. I'm using the MPG code from Init3AnalogPlusMPG.c. It *sorta* works, but strangely. When I turn the MPG slowly, it seems to work OK. But, once I turn it beyond a relatively slow speed, the axis being jogged takes off at a pretty good clip, and just runs, literally, forever.
> > > > > > > >
> > > > > > > > Next, I've got a bunch of "button" functions, some of which are trivial (Execute, Halt, spindle/coolant on/off), but others less so, and I wonder if they even CAN be implemented under KMotionCNC. With Mach3, my pendant is ordinarily operated by a macropump driver, so it's easy to keep Mach3 and the hardware in-sync, and the pendant driver knows the state of Mach3. This allows me to make the button functions "state-aware". For example, a single button will do a CycleStart if no G-code program is currently running, or a Stop, if a G-code program is currently running. I have another button that serves the dual functions of FeedHold/Rewind. With KMotionCNC, it appears to me not practical to duplicate this, since the DSP has no clue whether a program is running or not. Is that correct?
> > > > > > > >
> > > > > > > > Also, in Mach3, both G00 and manual toolchanges are terminated by pressing CycleStart, but it appears to me that in KMotionCNC, a G00 is terminated by hitting "Execute", but a manual toolchange, which pops up a dialog, can only be exited by hitting Enter, or clicking with the mouse. Is there a way around this, to make them both accept the same button-triggered action?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>